JavaScript® code executes in a web browser or inside other applications to perform functions that provide for a more personalized and richer experience than a static web page or other static content could provide. JavaScript® code is usually benign and often useful for the end user. However, a common malware exploit scheme involves having an end user unknowingly download malicious JavaScript® code onto his or her computer. Malicious code may be programmed to identify vulnerabilities on the victim's computer, such as a “heap spraying” vulnerability, or programmed to trigger a vulnerability in the JavaScript® renderer, in order to enable an attacker to do various things that an end user does not agree to and would not typically desire. For example, malicious code may compromise data on the end user's machine or cause the end user's machine to join a “botnet,” a group of computers that are at least partly under another person's control, often employed for nefarious purposes.
Traditionally, JavaScript® code samples were produced by the same person or persons that hoped to use them to compromise end user devices. Over time, however, the field has moved towards differentiation, with a small number of exploit kit providers providing exploit kits to their more numerous “customers” who use various means to trick end users into downloading the exploits onto their machines.
An exploit kit typically includes three basic components, an execution trigger, an unpacker, and a payload. The payload may include code that targets one or more Common Vulnerability and Exposures (CVEs) on the end user's machine. The payload is typically packed or obfuscated by the exploit kit provider in order to prevent easy identification of the JavaScript® code sample as malicious. The unpacker unpacks or de-obfuscates the payload.
The number of known vulnerabilities is relatively low, and thus the payload of exploit kits change relatively infrequently. Also, even where new CVEs are used, they are often simply appended to the existing payload code. However, an exploit kit provider can easily change relatively trivial aspects of the exploit kit, such as the unpacker code, thereby making existing anti-virus signatures that target previous versions of the exploit kit useless for identifying new versions. It may take several days to create an anti-virus signature for a new exploit kit, but mere minutes for the exploit kit provider to realize that the new signature is available and make a new version of the kit available. Anti-virus vendors and others that make it their business to protect users from malicious code are therefore in a constant arms race against the exploit kits providers.